home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Jun 88 / 101-just a silly method longer next >
Encoding:
Text File  |  1991-03-06  |  2.5 KB  |  57 lines  |  [TEXT/GEOL]
  1. Item    2002745                         28-June-88        09:06
  2.  
  3. From:   D0795                           Double Centre Surveying, Dev
  4.  
  5. To:     WILSON6                         Wilson, Dave - Personal Concepts
  6.  
  7. cc:     MACAPP$                         MacApp Interest List
  8.  
  9. Sub:    101-just a silly method longer
  10.  
  11. Dave,
  12.  
  13. I disagree with your statement that any class that has 100 methods (or more) is
  14. too large. I MAY agree with the statment about reusability.
  15.  
  16. Any limit set on the number of methods is by definition going to be arbitrary
  17. unless the specific application it will be used for the creation of is known
  18. about before seeting those limits. I feel that these limitations should not be
  19. imposed in order to 'enforce' good programming style, reusability of code, or
  20. any other rationalization for an artificially low limit.
  21.  
  22. Similar arguments can be made for limiting segment sizes to 32k, although I
  23. feel there are cases where this limit can be justified (not rationalized.)
  24.  
  25. My main argument is that at some point in the 'tree' of objects youy reach a
  26. 'leaf' level. Should we have to make another 'branch' just so our existing
  27. 'branch' doesn't get to heavy with 'leaves' ? I don't think so. I think that
  28. almost any limit to the number of methods could be agrued about (give them an
  29. inch…) but I think that the limitations put on us by setting the number of
  30. methods at 100 is too low.
  31.  
  32. Remember that Object Pascal is a hybrid that is supposed to make things easier.
  33. We are supposed to be able to code quicker. We are not supposed to have to
  34. re-design or classes just because we passed some imaginary line ! The reason
  35. that Apple stuck with an existing language instead of going to another was to
  36. make the transition as painless as possible while preserving the ability to use
  37. procedural approaches when they make the best sense.
  38.  
  39. I want to write the code that best fits MY needs not the needs of a language
  40. designer. I want to produce applications NOT examples of 'good' object-oriented
  41. programming.
  42.  
  43. I didn't intend to get up on a soapbox but this limit was a rael problem for us
  44. at a point when we were about to ship the first version of a new product. We
  45. lost a couple of weeks to it.
  46.  
  47. Thanx,
  48. John D. Olsen, RPS
  49.  
  50. P.S. Dave Wilson probably knows quite alot more than I do about Object-Oriented
  51. Programming. His points are well taken for MOST cases.
  52.  
  53. P.S.S Senior Bianchi's point about the limitation's being in the compiler is
  54. correct. I incorrectly stated that it was related to MacApp which is not
  55. correct. I stand corrected.
  56.  
  57.